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FOREWORD 

This  first  volume  of  the  Final  Technical  Report  describes  the  significance  and  presents  a 
high  level  overview  of  Air  Force  Contract  F33615-85-C-5122,  Geometric  Modeling  Applications 
Interface  Program  (GMAP),  covering  the  period  1  August  1985  to  31  March  1989.  The  contract 
was  sponsored  by  the  Manufacturing  Technology  Directorate,  Wright  Research  &  Development 
Center,  Air  Force  Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio,  45433-6533.  This 
pvogram  was  administered  under  the  technical  direction  of  Mr.  Charles  R.  Gilman. 

The  primary  contractor  was  Pratt  &  Whitney,  an  operating  unit  of  United  Technologies 
Corporation  (UTC).  Pratt  &  Whitney  engaged  several  additional  firms  as  subcontractors, 
including  United  Technologies  Research  Center  (UTRC),  McDonnell  Aircraft  Company 
(MCAIR),  and  International  TechneGroup  Incorporated  (ITI),  to  assist  in  various  tasks  of  the 
program.  At  Pratt  &  Whitney,  the  program  was  managed  by  Mr.  Richard  Lopatka.  Ms.  Linda 
Phillips  was  the  Program  Integrator,  and  Mr.  John  Hamill  was  the  Deputy  Program  Manager. 

Note:  The  number  and  date  in  the  upper  right  corner  of  each  page  of  this  document  indicate 
that  the  volume  has  been  prepared  according  to  the  ICAM  CM  Life  Cycle  Documentation 
requirements  for  a  Configuration  Item  (Cl). 
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1.1  DOCUMENT  FOCUS 

This  Executive  Overview  volume  of  the  GMAP  Final  Report  is  aimed  at  the  management 
level  of  industry  and  Government.  The  document’s  sole  purpose  is  to  provide  a  high  level 
summary  of  the  GMAP  work  and  relay  the  significance  of  the  results  to  both  industry  and  the 
Government  to  assist  them  in  determining  the  appropriate  next  steps  to  be  taken. 

1.2  PROGRAM  FOCUS 

The  primary  focus  of  GMAP  was  the  generation,  control,  and  exchange  of  computerized 
product  model  information  that  will  replace  traditional  design  and  manufacturing  drawings.  This 
product  model  information  is  referred  to  as  Product  Definition  Data  (PDD)  throughout  the 
GMAP  documents. 

The  requirement  for  GMAP  stemmed  from  the  increasing  use  of  geometric  modeler-based 
software  systems  in  aerospace  product  life  cycle  operations.  There  was  a  need  to  share 
information  produced  by  these  systems  in  an  efficient  and  cost-effective  manner.  Today,  it  is 
becoming  more  important  for  major  manufacturers  to  be  able  to  share  computerized  product 
information  with  nearly  all  internal  product  life  cycle  operations,  as  well  as  with  partners, 
suppliers,  and  customers.  This  product  information  goes  beyond  the  geometric  modeler-based 
data  that  are  readily  available  from  the  Computer  Aided  Design  (Drafting)  and  Computer  Aided 
Manufacturing  (CAD/CAM)  systems  in  use. 

1.3  BACKGROUND 

The  need  for  a  means  to  exchange  PDD  began  in  the  late  1970s  with  the  growth  of 
minicomputer-based  CAD/CAM  systems.  Since  then,  several  initiatives  have  been  undertaken 
that  deal  with  the  problems  of  data  exchange  among  the  different  CAD/CAM  hardware  and 
software  platforms.  The  Initial  Graphics  Exchange  Specification  (IGES)  is  the  most  well  known 
of  these  initiatives. 

1.3.1  Product  Definition  Data  Interface 

In  1982,  the  Air  Force  funded  the  Product  Definition  Data  Interface  (PDDI)  program  to 
determine  the  feasibility  of  using  computerized  PDD  as  the  primary  means  of  communicating 
engineering  information  to  manufacturing.  This  program  had  two  main  tasks:  (1)  to  evaluate  and 
verify  the  then  current  standard,  ASME/ANSI  Y14.26M-1981  (sometimes  referred  to  as  IGES 
Version  1.0)  for  PDD  exchange  and  (2)  using  the  results  of  the  first  task,  demonstrate  a 
prototype  system  that  integrates  engineering  and  manufacturing  using  the  electronic  equivalent 
of  a  blueprint. 
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The  results  of  the  PDDI  program  were  quite  significant.  In  fact,  the  results  were 
instrumental  in  starting  several  large-scale  initiatives  within  both  industry  and  the  DoD.  The 
major  findings  of  PDDI  Task  I  were: 

•  IGES  was  capable  of  representing  computer-aided  drafting  models,  but  could 
not  support  the  informational  needs  of  manufacturing. 

•  IGES  translators  were  less  adequate  than  expected  with  respect  to  comple¬ 
teness  and  correctness  of  translation. 

Based  on  the  Task  I  findings,  PDDI  Task  II  was  initiated  to  build  a  prototype  system  that 
could  support  the  informational  needs  of  manufacturing.  This  would  be  accomplished  by 
providing  an  interface  “system”  between  engineering  and  manufacturing.  This  interface 
“system”  was  successfully  demonstrated  and  discussed  at  the  PDDI  end-of-contract  executive 
debriefing  held  in  September  1985.  During  the  PDDI  efforts,  sufficient  industry  interest  was 
generated  in  1984  to  initiate  the  PDES  task  within  the  National  Bureau  of  Standards’  IGES 
organizati'  n.  At  the  same  time,  the  United  States  joined  forces  with  other  countries,  through  the 
Internationi.’  Standards  Organization  (ISO),  to  develop  a  single  worldwide  standard  for  the 
exchange  of  pi  duct  data.  The  goal  of  these  efforts  is  “...the  capture  of  information  comprising  a 
computerized  product  model  in  a  neutral  form. ..throughout  the  life  cycle  of  the  product.” 

1.3.2  Role  of  GMAP 

To  get  a  better  understanding  of  the  informational  needs  for  computerized  product  data 
throughout  the  life  cycle  of  a  product,  the  Air  Force  funded  the  Geometric  Modeling  Applications 
Interface  Program  (GMAP)  as  a  follow-on  to  the  PDDI  program.  Using  the  PDDI  system  as  a 
baseline,  GMAP  further  developed  an  architecture  for  data  exchange. 

GMAP  focused  on  the  development  of  a  specification  for  complete  PDD.  Demonstrations 
were  conducted  to  show  that  this  information  could  be  communicated  via  a  computer  PDD  part 
model  to  numerous  life  cycle  applications  within  Pratt  &  Whitney,  at  supplier  facilities,  and 
within  Air  Force  Logistic  Centers.  Further,  it  demonstrated  the  ability  to  share  this  information 
across  a  variety  of  computer  and  software  platforms. 

During  GMAP  (1985-1989),  several  events  took  place  which  resulted  in  GMAP  achieving 
more  positive  results  then  originally  anticipated. 

First,  in  September  1985,  the  Deputy  Secretary  of  Defense  launched  the  Computer-aided 
Acquisition  and  Logistics  Support  (CALS)  program.  The  various  DoD  agency  thrusts  in  the  area 
of  digital  data  exchange  were  focused  through  the  establishment,  in  October  1986,  of  the  CALS 
Policy  Office  by  the  Under  Secretary  of  Defense  for  Acquisition.  The  responsibility  of  this  office 
was  to  guide  the  development  and  implementation  of  CALS  data  exchange  standards,  advocate 
their  integration  into  military  information  systems  and  weapon  acquisition  programs,  and 
provide  a  single  DoD  interface  to  industry  on  CALS  data  exchange.  GMAP  was  designated  a 
CALS  system  integration  and  architecture  program  in  1986. 

Second  was  the  establishment,  in  April  1988,  of  PDES,  Inc.,  a  joint  industry  and 
Government  effort  to  accelerate  the  development,  validation,  and  implementation  of  the  Product 
Data  Exchange  Specification  (PDES).  This  36-month  program  consists  of  two  phases.  Phase  1 
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fjcuses  on  validation  and  implementation  of  a  subset  of  the  PDES  submitted  to  ISO  as  a  draft 
standard.  The  emphasis  of  this  work  is  on  data  exchange.  Phase  II  will  switch  the  focus  from 
exchange  to  integration  of  data  and  will  broaden  the  PDES  subsets  to  include  electronic  parts. 
The  results  of  GMAP  are  anticipated  to  be  useful  to  this  group  by  assisting  them  in  building 
models  for  testing  and  validation  of  PDES  and  by  supplying  an  architecture  for  implementation. 

Third  was  the  reorganization  of  the  National  Bureau  of  Standards  into  NIST,  the  National 
Institute  for  Standards  and  Technology,  and  the  establishment  of  a  National  PDES  testbed.  The 
GMAP/PDDI  software  components  and  architecture  concepts  were  adopted  in  June  1989  to 
form  the  baseline  system  for  the  development  of  the  structure  needed  to  support  the  National 
testbed. 

The  GMAP  system  software  installed  at  NIST  is  being  made  available  to  industry  to  test 
the  evolving  PDES  specification.  Testing  PDES  in  the  GMAP  environment  includes  the  creation 
of  produ.c  model  instances  in  the  PDES  information  structure,  and  the  development  and 
evaluation  of  application  programs  against  those  product  models.  The  tools  with  which  this  cm 
be  accompli^ed  are  part  cf  the  GMAP  system  architecture.  The  GMAP  system  at  NIST,  along 
with  the  provi  'ed  PDES  physical  implementation  files,  supports  every  entity  in  the  PDES 
specification.  Pres  'ntly,  it  is  believed  to  be  the  only  facility  available  to  general  industry  that  can 
make  this  claim.  As  such,  the  interest  in  this  environment  should  continue  to  be  very  high. 

Furthermore,  with  minimal  effort,  the  PDES  specification  upon  which  the  system  operates 
can  be  replaced  with  future  versions  of  the  PDES  specification  using  the  data  independence  of 
the  GMAP  system  architecture. 
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SECTION  2 
SCOPE  OF  GMAP 

GMAP  focused  on  the  generation,  control,  and  exchange  of  computer  information  to 
replace  traditional  design  and  manufacturing  drawings.  The  goal  was  to  improve  communication 
between  aerospace  prime  contractors  and  their  partners,  multiple  tiers  of  subcontractors, 
military  and  commercial  users  of  aerospace  products,  and  supporting  agencies.  In  performing  the 
tasks  associated  with  the  program,  several  issues  that  the  Air  Force  had  identified  were 
addressed.  These  issues  are  outlined  below. 

2.1  DESIRE  FOR  DIGITAL  DATA 

Both  the  GMAP  and  the  PDDI  programs  were  undertaken  by  the  Air  Force  as  part  of  their 
attempt  to  deal  with  their  problem  of  paper  drawings  and  the  communication  of  ..lgineering 
data.  While  a  single  company  may  have  millions  of  drawings,  the  Air  Force  has  billions!  The 
efforts  relating  to  the  use  and  maintenance  of  th«  paper  drawings  that  are  stored  in  the  data 
repositories  were,  and  still  are,  a  massive  and  ver>  expensive  problem.  The  Air  Force,  as  well  as 
the  other  military  services,  looked  for  some  time  to  find  alternative  approaches.  As  several 
initiatives  were  undertaken  in  the  late  1970s  and  early  1980s  to  deal  with  the  paper  through  the 
rse  of  raster  technology,  the  Air  Force  began  to  take  a  harder  look  at  the  need  communication, 
snd  use  of  this  engineering  data.  They  found  that  although  paper  drawings  serve  a  useful 
purpose,  the  real  need,  and  potentially  higher  cost  savings,  was  found  to  be  in  the  ability  to 
communicate  the  engineering  data  in  intelligent  computerized  form.  One  of  the  first  eructations 
for  GMAP  was  that  we  would  be  able  to  completely  replace  the  existing  paper  documents  with 
computerized  data. 

2.2  EXPAND  FOCUS  TO  LOGISTICS 

Most  of  the  PDD  research  prior  to  GMAP  was  on  the  informational  needs  of  manufactur¬ 
ing.  The  Air  Force  wanted  to  factor  in  the  informational  needs  of  Logistics  Support.  Part  of  the 
Air  Force’s  modernizations  efforts  was  to  introduce  automation  into  the  Logistic  Centers.  In 
moving  from  manual  to  automated  inspection  systems,  the  Air  Force  found  that  there  was  a  need 
to  build  interfaces  to  these  systems  so  that  they  could  access  the  computerized  data  instead  of 
manually  re-entering  this  information.  They  felt  that  thi«*  would  reduce  lead  time,  reduce  input 
errors,  and  improve  accuracy.  The  Air  Force  hoped  that  GMAP  would  provide  an  interface  to  two 
existing  functional  applications:  IBIS  (Integrated  Blade  Inspection  System)  and  RFC  (Retire¬ 
ment  for  Cause).  Both  of  these  systems  were  highly  automated  but  required  a  lengthy  lead  time 
to  reproduce  the  part  models  from  the  paper  drawings.  It  was  felt  that  the  cost  of  creating  the 
scan  plans  could  be  greatly  reduced  by  applying  GMAP  interfaces  to  these  systems. 

2.3  GEOMETRIC  MODELING  DISCONNECTS 

Geometric  modelers  in  current  product  life  cycle  applications  use  a  number  of  ferent 
techniques  to  create,  represent,  and  manipulate  PDD.  The  most  mature  of  these  systems  can  be 
classified  into  three  general  categories:  wireframe,  surface,  and  solid.  More  recently,  two 
additional  categories  have  developed:  feature-based  and  object  oriented.  Communicating 
information  between  these  systems  results  in  a  loss  of  information  and  is  very  difficult  because 
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there  are  disconnects  in  the  kind  of  data  and  the  relationships  between  the  data.  It  was  expected 
that  GMAP  would  inestigate  approaches  to  minimize  the  movement  of  data  and  develop  a 
method  for  allowing  this  communication  without  data  loss.  A  method  to  share  data  in  an 
integrated  environment  was  anticipated. 

2.4  INCOMPLETE  PDD 

When  the  Air  Force  began  the  PDDI  progium  in  1982,  most  CAD/CAM  systems  "’ere  still 
based  on  the  philosophy  that  the  end  result  was  to  produce  a  paper  drawing.  These  systems  ali 
supported  the  ability  to  create,  manipulate,  and  communicate  geometric  and  annotation 
information.  However,  most  could  not  support  the  data  that  was  being  defined  by  PDDI  (and 
GMAP)  as  being  necessary  to  build  complete  part  models.  This  information  included 
administrative,  assemb’ . ,  topology,  feature,  tolerance,  and  nonshape  data.  It  was  anticipated  that 
the  GMAP  project  would  develop  a  complete  specification  for  this  information  and  develop  a 
prototype  means  to  build  the  part  models. 

2.5  UNREACHABLE  DOWNSTREAM  APPLICATIONS 

It  has  often  been  said  that  manufacturing  does  not  use  the  information  supplied  by 
(  ngineering  because  the  data  are  not  in  the  desired  format  and,  mor.  >ften  than  not,  they  are  not 
the  information  required.  Basically,  the  problem  is  due  to  the  way  each  of  the  life  cycle  groups 
view  the  part  and  their  need  for  the  information.  An  engineer,  for  example,  might  look  at  a 
workpiece  with  a  hole  in  it  and  see  stress  problems;  a  manufacturer  looking  at  the  same 
workpiece  and  the  same  hole  could  see  drilling  procedures.  Since  engineering  is  the  creator  of  the 
information,  they  normally  create  only  the  information  that  they  require.  Thus,  the  downstream 
applications,  manufacturing  and  support,  which  are  in  need  of  supplemental  information,  are  not 
satisfied.  It  was  anticipated  that  the  GMAP  project  would  provide  a  detailed  analysis  of  the  life 
cycle  information  needs  and  help  define  the  requirements  of  a  modeling  system  to  satisfy  these 
needs. 
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SECTION  3 

MAJOR  PROGRAM  ACCOMPLISHMENTS 


The  successful  completion  of  GMAP  can  be  measured  by  the  accomplishments  achieved  in 
satisfying  the  goals  and  objectives  of  GMAP.  The  major  accomplishments  are  described  below. 

3.1  COMPLETE  REPRESENTATION  IN  DIGITAL  FORM 

Prior  to  the  GMAP  effort,  the  computerization  of  all  information  needed  to  support  a 
product  throughout  its  lifecycle  had  not  been  studied  in  detail.  GMAP  successfully  conducted  a 
thorough  investigation  on  such  information  for  turbine  blades  and  disks.  These  parts  were 
selected  because: 

•  They  had  a  wide  range  of  simple  and  complex  geometries  (defined,  undefined, 
internal,  and  external  surfaces). 

•  They  provided  a  vehicle  to  determine  the  nongeometric  information  that  is 
required,  but  not  normally  conveyed,  electronically  with  the  geometric 
information. 

It  was  believed  that  if  the  information  associated  with  these  parts  could  be  identified  and 
organized,  then  it  was  possible  to  do  the  same  for  any  part  family.  The  result  of  this  effort  was 
that  an  information  structure,  or  schema,  was  created  that  was  capable  of  supporting  the  data 
needs  of  the  applications  throughout  the  lifecycle. 

In  the  process  of  studying  these  data,  it  was  determined  that  they  could  be  categorized  into 
distinct  data  classes:  Administrative,  Assembly,  Tolerance,  Nonshape,  Topology,  Form  Features, 
and  Geometry.  Most  of  the  work  involved  in  categorizing  was  in  understanding  how  the 
applications  used  the  data.  Once  that  was  done,  information  diagrams  were  constructed  using 
information  modeling  techniques.  These  diagrams  created  a  visual  record  of  the  information 
needs. 

The  actual  integration  process  involved  organizing  the  data  classes  into  one  integrated 
model.  There  was  some  difficulty  in  relating  the  nonshape  information  (Administrative, 
Assembly,  Tolerance,  and  Nonshape)  with  the  physical  shape  of  the  part.  This  resulted  in 
developing  an  additional  class,  the  Shape  data  class.  In  relating  the  findings  to  the  PDES 
community,  it  was  recommended  that  PDES  be  organized  along  the  concept  of  the  Shape  data 
class.  The  PDES  organization  adopted  this  approach  in  1988. 

As  complete  models  of  the  GMAP  parts  were  developed,  limits  that  exist  within  the  current 
implementations  of  today’s  CAD/CAM  systems  were  encountered.  These  limits  were  such  things 
as  available  computer  memory,  number  of  allowable  entities,  and  database  relationships.  For 
example,  it  was  discovered  that  complete  PDD  part  models  were  significantly  lsrger  than  the 
current  CAD/CAM  part  models.  Also,  in  building  the  solid  model  of  the  turbine  blade,  we  were 
restricted  by  the  number  of  facets  in  a  solid,  which  prohibited  the  addition  of  much  of  the 
“small”  geometric  entities,  such  as  fillets,  trip  strips,  and  cooling  holes.  We  could  not  put  all  of 
the  fillets  in  the  model,  and  some  of  the  boolean  operations  would  not  execute  as  expected. 
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Further,  we  observed  that  the  addition  of  the  nongeometric  PDD  only  encompassed  2  percent  of 
the  total  model  size.  This  is  not  true  of  the  disk  model  built  for  GMAP,  where  nongeometric 
information  encompassed  73  percent  of  the  total  model.  We  estimated  that  a  complete  model  of  a 
GMAP  turbine  blade  would  require  approximately  80  megabytes  of  disk  storage.  Until  the  above 
mentioned  limitations  can  be  dealt  with,  they  will  constrain  the  development  of  complete  part 
models, 

3.2  DEMONSTRATED  PDD  EXCHANGE 

Once  the  analysis  of  the  information  needed  to  support  the  life  cycle  was  completed,  it  was 
necessary  to  test  the  findings  and  demonstrate  the  results.  To  demonstrate  success  throughout 
the  total  life  cycle,  a  sampling  of  applications  that  represented  a  rigorous  cross  section  of  the  life 
cycle  was  selected  for  demonstration.  Our  criteria  for  selection  was  based  on  problem-solving 
techniques  used  by  Pratt  &  Whitney’s  internal  Q+  process.  This  resulted  in  our  using  five  basic 
questions  to  review  the  applications  for  selection: 

1.  How  important  is  this  application  to  the  full  life  cycle  coverage  of  turbine 
blades  and  disks? 

2.  What  is  the  breadth  of  the  functional  application  in  the  full  life  cycle 
coverage? 

3.  What  is  the  depth  of  the  functional  application  in  terms  of  producing  or 
consuming  PDD? 

4.  If  this  application  is  supported,  how  much  enhancement  or  advancement  (in 
the  use  of  PDD)  will  be  enabled? 

5.  Does  the  application  meet  the  requirements  of  the  GMAP  contract? 

Potential  functional  application  areas  were  evaluated  based  on  the  above  criteria. 
Seventeen  key  functional  applications  were  identified  by  the  GMAP  team.  These  were  reviewed 
with  the  Air  Force  and  the  GMAP  Industry  Review  Board  (IRB).  Thirteen  were  finally  selected 
for  demonstration  and  are  identified  in  Table  3-1. 

During  the  selection  process,  it  was  discovered  that  few  existing  applications  existed  that 
could  use  the  nongeometric  PDD.  A  3-D  N/C  and  CMM  programming  application  (item  9  in 
Table  3-1)  was  developed  to  demonstrate  the  use  of  form  features  and  nonshape  information  to 
automate  the  generation  of  N/C  programs  and  CMM  programs. 

Three  video  tapes  were  created  to  document  the  GMAP  demonstrations.  There  is  one  on 
the  disk  life  cycle,  one  on  the  blade  life  cycle,  and  a  third  focusing  on  an  engine  case  plumbing 
attachment  boss.  The  two  life  cycle  video  tapes  show  how  the  data  exchange  and  the  applications 
can  be  improved  by  having  complete  PDD  part  models  available.  The  case  boss  video  tape  was 
created  to  illustrate  a  part  more  typical  of  industry  outside  of  aerospace. 
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TABLE  3-1. 

SELECTED  DEMONSTRATION  APPLICATIONS 


1.  Detailed  Blade  and  Disk  Design  and  Analysis 
Final  Blade  and  Disk  Design  and  Analysis 

(Detailed  and  final  blade  and  disk  design  and  analysis  are  grouped  together  because  of 
common  applications.) 

a)  Parametric  cooled  turbine  blade  and  disk  design  (includes  core  and  cooling  holes) 

b)  Design  Verification  and  Analysis 

c)  Aerodynamic  Design  Surface  Verification 

2.  Detailed  Engineering  Specifications 

a)  Nonshape  and  tolerance  PDD  creation 

3  Quality  Requirements  Engineering 
'  PROcess  CAPability  (PROCAP) 

4.  Catet  ->rize  and  Review  Parts/Processes 

5.  General  Process  Planning 

a)  Data  feed  to  computer-aided  process  planning 

6.  Casting  Process  Planning 

a)  Airfoil  casting  simulation  using  finite  element  analysis  (feature  based  solid  model) 

7.  Numerical  Control  (N/C)  Programming  for  Airfoil  Casting  Molds  and  Dies  and  Tool 

Design 

8.  Disk  Forging 

9.  N/C  Programming  —  Disk  Machining 

a)  3-D  N/C  and  coordinate  measuring  machine  (CMM)  programming  for  disks 

10.  Program  rung  Automated  Inspection  Devices 

a)  Robotic  inspection  devices 

b)  Coordinate  measuring  machine  inspection  of  case  bosses  using  DMIS  language 

11.  Programming  Automated  Devices 

a)  Robotic  debarring  of  turbine  blades  or  disks 

12.  The  Air  Force  Integrated  Blade  Inspection  System  for  airfoils  at  San  Antonio  Air 

Logistics  Center 

13.  The  Air  Force  Retirement  for  Cause  disk  inspection  system  at  San  Antonio  Air  Logistics 

_ Center _ _ _ _ 

RMermo 


3.3  PROVIDED  ARCHITECTURE  AND  SOFTWARE  FOR  DATA  EXCHANGE 

When  GMAP  began,  it  was  not  certain  that  the  software  approach  taken  on  the  PDDI 
program  was  appropriate  to  support  the  GMAP  requirements.  The  PDDI  approach  developed  a 
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prototype  for  a  software  architecture,  which  upon  first  examination,  appeared  to  complicate  the 
process  of  data  exchange.  The  PDDI  software  had  performance  problems,  and  its  overall  merits 
were  still  being  debated  by  the  PDDI  IRB.  Also,  during  the  development  of  the  PDDI 
demonstrations,  one  of  the  CAD/CAM  developers  opted  to  bypass  the  use  of  the  PDDI  software 
completely  and  build  a  direct  PDDI  translator  to/from  their  system  using  the  same  interface 
philosophy  as  IGES.  However,  once  all  the  PDDI  demonstration  results  were  complied,  it  was 
obvious  that  those  who  chose  to  use  the  PDDI  software  were  able  to  implement  complete  data 
exchange  using  the  PDDI  translator  more  quickly  and  more  accurately. 

Early  in  GMAP,  a  new  approach  was  contemplated.  However,  the  time  and  risk  factor 
involved  did  not  warrant  exploring  new  alternatives.  As  the  needs  and  requirements  were  being 
determined,  it  became  more  evident  that  the  PDDI  software,  with  some  modifications,  would  be 
capable  of  satisfying  our  requirements.  This  decision  was  substantiated  by  our  State-of-the-Art 
survey,  which  indicated  that  the  PDDI  approach  was  the  best  to  pursue. 

The  GMAP/PDDI  system  components  and  software  architecture  are  explained  in  detail  in 
the  GMAP  System  Specification  (SS560240001U).  However,  it  is  important  to  understand  how 
this  architec,  ’re  differs  from  the  type  of  interfaces  that  were  being  developed  for  IGES. 

Prior  to  PDlT  and  GMAP,  the  primary  means  of  data  exchange  were  through  the  use  of 
IGES.  Interfaces  were  created  by  writing  a  program  which  would  interrogate  the  native  database 
of  a  CAD/CAM  system  and  create  a  file  in  the  IGES  file  format.  Likewise,  using  the  IGES  file  as 
input,  a  file  would  be  built  in  the  native  database  of  the  CAD/CAM  system.  These  interfaces 
were  usually  not  robust  enough  to  handle  all  possible  IGES  information.  As  pointed  out  in 
Section  1,  the  PDDI  program  determined  that  the  existing  IGES  translators  were  less  adequate 
than  expected  with  respect  to  completeness  and  correctness  of  translation. 

Under  PDDI  and  GMAP,  a  set  of  software  tools  which  provided  a  robust  environment  for 
this  data  translation  was  created.  This  software  was  implemented  on  various  computer  hardware 
platforms  and  operating  systems  to  prove  that  it  was  flexible.  It  has  been  implemented,  and 
successfully  tested,  on  IBM  TSO  and  VM/CMS,  DEC  VAX  VMS,  and  SUN  UNIX. 

3.4  IDENTIFIED  REQUIREMENTS  FOR  “PRODUCT  MODELER” 

In  1985,  the  majority  of  the  CAD/CAM  industry  was  still  thinking  along  the  lines  of  CAD 
models  and  geometric  information.  Only  a  few  organizations  had  embraced  the  idea  of  PDD  and 
product  models  that  had  come  out  of  the  PDDI  program.  As  part  of  the  GMAP  contract,  it  was 
necessa»y  to  establish  the  minimum  requirements  of  a  Geometric  Modeling  System.  In 
performing  this  task,  it  was  determined  that  the  requirements,  and  limitations,  of  a  geometric 
modeling  system  were  well  understood.  What  needed  to  be  investigated  was  the  minimum 
requirements  of  a  Product  Modeler.  This  was  accomplished  and  submitted  to  the  Air  Force  as 
Appendix  D  of  the  GMAP  System  Requirements  Document  (SRD560240001U). 

Upon  closer  review  by  the  GMAP  IRB,  the  Product  Modeler  Document  was  found  to  raise 
more  questions  than  it  answered.  The  Air  Force  and  the  GMAP  team  determined  that  a  more 
rigorous  investigation  needed  to  be  performed.  This  was  accomplished  under  an  extension  to  the 
original  contract  and  was  published  as  a  separate  technology  transfer  document,  Functional 
Requirements  of  a  Product  Modeler  (TTD560240001U).  The  document  was  written  to  convey  to 
industry  the  concepts  developed  within  GMAP,  and  provide  an  architecture  for  development  of  a 
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product  modeler  system.  It  identifies  modules  of  the  system  and  the  interdependence  of  these 
modules  The  primary  intent  is  to  convey  an  industry-focused  view  on  the  concepts  and 
requirements  of  a  product  modeler  such  that  commercialization  of  this  technology  can  respond  to 
generic  industry  needs. 

3.5  HEIGHTENED  INDUSTRY  TECHNOLOGY  AWARENESS/UNDERSTANDING 

The  PDDI  program  resulted  in  the  engineering  community  better  understanding  the  needs 
of  manufacturing.  For  the  first  time,  a  thorough  analysis  of  the  manufacturing  needs  for  PDD 
was  documented  and  discussed  in  an  open  forum  with  prime  aerospace  manufacturers  including 
Avco,  Boeing,  General  Dynamics,  General  Electric,  Lockheed,  and  United  Technologies.  This 
resulted  in  a  core  group  of  industries,  primarily  airframe  manufacturers,  that  understood  the 
content  of,  and  the  need  for,  PDD. 

GMAP  enlarged  this  small  core  group  by  including  the  technology  users  and  developers  on 
the  IRB.  We  included  gas  turbine  engine  manufacturers,  airframe  manufacturers,  major  gas 
turbine  engine  subcontractors,  computer  system  manufacturers,  and  industry  manufacturers 
outside  of  aerospace.  Table  3-2  contains  a  listing  of  the  IRB  members  and  respective  companies. 
This  broad  cross  section  of  U.S.  industry  resulted  in  very  lively  IRB  meetings.  The  IRB  members 
provided  direction  as  to  the  prioritization  of  needs,  appropriateness  of  solutions,  and  soundness 
cf  technical  content. 

In  addition  to  the  15  members,  the  IRB  meetings  were  open  to  U.  S.  companies, 
Government  agencies,  and  universities.  Attendance  at  IRB  meetings  ranged  from  40  to  100 
people.  This  forum  enabled  transfer  of  the  GMAP  findings  to  numerous  industries  and 
organizations.  It  also  resulted  in  the  GMAP  mailings  list  growing  to  over  200  recipients. 
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TABLE  3-2. 

IRB  MEMBERSHIP 


Chairman  Members 

Mr.  George  J.  Hess  Jim  Hutto 

Ingersoll  Milting  Machine  Co.  Intergraph  Corporation 


Secretary 

Jason  (Jack)  Lemon 

International  TechneGroup  Incorporated 

Members 

Robert  Badgett 
ComputerVision  Corporation 

Jack  Conaway  and  Ulrick  Flatau 
Digital  Equipment  Corporation 

Calvin  W.  Emmerson 
Allison  Gas  Turbine  Division 

S.  J.  (Jeane)  Ford 
International  TechneGroup  Inc. 

Donald  J.  Gregory 
General  Electric/AEBG 


Chris  Klomp  and  Mike  McClure 
Boeing  Company 

Robert  Krakowsky  and  Stan  Pickford 
Wyman-Gordon  Company 

Don  Manor 
Deere  &  Company 

Robert  L  McMahon,  Jr. 

General  Dynamics 

Donald  Moran 
Textron  M&MTC 

Chet  Moutrie 

Control  Data  Corporation 

Ed  Schumacher 

Avco  Aerostructures  Textron _ 
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SECTION  4 
MAJOR  ISSUES 

4.1  NEED  FOR  PRODUCT  MODELER 

The  GMAP  software  and  schema  were  created  to  demonstrate  proof-of-concepts  and  to 
assist  the  national  effort  in  development  of  PDES  as  an  American  national  standard.  The  intent 
was  that  production  implementation  would  not  occur  until  PDES  was  sufficiently  developed. 
GMAP  provided  a  learning  tool  for  those  involved  to  better  understand  the  problems  that  would 
be  associated  with  the  eventual  implementation  of  PDES.  From  the  GMAP  point  of  view,  the 
readiness  to  implement  is  most  severely  constrained  by  one  major  technology  shortfall  —  the 
unavailability  of  a  product  modeler. 

During  GMAP,  the  concept  of  a  product  modeler  evolved.  Simply  put,  a  product  modeler  is 
»  software  tool  that  ''an  be  used  to  define  “all”  of  the  data  necessary  to  describe,  use,  and  share  a 
product  completely,  accurately,  and  unambiguously.  This  differs  from  today’s  CAD/CAM 
systems,  or  geometric  modelers,  which  typically  only  define  the  physical  (geometric)  shape  of  a 
product.  Currently,  there  is  no  efficient  software  tool  that  will  support  the  creation  of  a  complete 
PDD  model.  PDES  will  define  the  specification  for  the  information  that  needs  to  be 
communicated;  it  will  not  define,  nor  create,  the  software  tool  to  actually  build  the  models.  Our 
recommendations  on  the  development  of  a  product  modeler  are  outlined  in  Section  5.3 

The  GMAP  component  software  that  is  deliverable  under  the  contract  is  not  dependent 
upon  the  development  of  PDES.  In  fact,  this  software  was  installed  at  NIST  to  support  the 
testing  of  PDES  as  it  evolves.  The  software  will  be  used  as  a  baseline  and  can  be  modified,  as 
needed,  by  the  PDES  Inc.  organization  to  support  the  development  of  the  PDES  draft. 

The  GMAP-to-RFC  and  GMAP-to-IBIS  Interfaces  were  also  deliverables  under  the 
contract.  These  Interfaces  are  production  worthy  and  are  constrained  in  that  they  need  PDD 
models  in  GMAP  format.  The  prototype  GMAP  Interfaces  can  be  modified  once  PDES  is 
available  so  that  PDD  models  can  be  supplied  in  the  standard  neutral  format.  To  date,  the 
GMAP-to-IBIS  Interface  is  being  used  in  a  semi-production  mode.  Pratt  &  Whitney  has  supplied 
four  additional  blade  models  (from  four  different  stages  of  the  F100  engine  compressor)  to 
SA-ALC  for  use  in  IBIS.  No  plans  for  the  GMAP-to-RFC  Interface  have  been  developed. 

The  remaining  interfaces  built  to  support  the  proof-of-concept  demonstration  are  not  being 
pursued  at  this  time.  As  previously  stated,  the  lack  of  a  product  modeler  prevents  the  efficient 
creation  of  the  needed  PDD  models.  Presently,  the  cost  of  manually  creating  the  models  is 
prohibitive.  Driven  by  the  need  to  cut  costs  and  lead  times,  we  find  the  corporate  culture  ready  to 
embrace  PDD  technology.  While  we  work  with  the  system  developers  and  the  rest  of  industry  to 
develop  software  tools  (product  modeler/PDES),  the  GMAP  concepts  of  PDD  part  models  are 
being  incorporated  into  the  strategic  planning  of  future  production  systems. 
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4.2  OTHER  BARRIERS  TO  IMPLEMENTATION 

In  addition  to  the  lack  of  a  product  modeler,  there  are  a  few  technical  issues  that  stand  in 
the  way  of  total  implementation.  These  issues  need  to  be  addressed  in  a  cooperative  industry 
setting  involving  system  suppliers  and  the  users.  There  are  basically  four  areas  of  concern. 

1.  There  is  a  fundamental  technology  shortfall  that  requires  research  and 
development. 

2.  Product  data  transfer  exchange  capabilities  are  in  a  highly  dynamic  and 
evolving  environment,  which  makes  implementation  and  standards  extreme¬ 
ly  difficult  to  manage. 

3.  Product  data  transfer  must  be  addressed  in  light  of  the  entire  life  cycle, 

-  introducing  integration  challenges. 

4.  Special  DoD  requirements  compound  the  general  industry  requirements. 

4.2.1  Technology  Shortfalls 

•  Lack  of  full  product  description  databases  (and  database  management 
systems)  —  The  database  structures  to  represent  and  manage  product  data 
have  not  been  totally  defined.  The  database  software  to  manage  these 
structures  are  still  in  prototype  mode.  Product  Definition  Data  Interface 
(PDDD/GMAP  is  representative  of  this  capability.  The  electronic  versions  of 
engineering  drawings  do  not  include  all  the  data  necessary  for  all  the 
applications  throughout  product  life  cycle  operations  to  be  able  automatically 
to  use  that  original  drawing. 

•  Lack  of  a  full  product  modeler  —  The  solids  modelers  that  exist  today  do  not 
allow  a  user  to  enter  everything  necessary  to  generate  full  product  description 
databases.  Today’s  modelers  are  good  at  creating  geometry  and  topology,  but 
fail  to  provide  computer  sensible  information  such  as  tolerancing,  features, 
and  notes.  Input  to  the  database  is  currently  a  significant  technology  barrier. 

•  Shortfalls  in  applications  ready  to  use  PDD  —  Since  there  is  a  lack  of  full 
product  description  databases,  there  are  very  few  existing  applications 
capable  of  using  such  a  database. 

•  Lack  of  configuration  control  capability  —  There  is  a  need  for  better 
traceability  of  product  design  releases.  Current  product  designs,  as  well  as 
designs  of  mature  products,  and  their  revisions,  must  be  retrievable  and 
accurately  associated  among  operations  within  an  enterprise.  There  is  a  great 
deal  of  manual  verification  currently  taking  place. 

•  Lack  of  PDD  communications  network  —  Today’s  communication  networks 
are  not  designed  to  handle  the  massive  amount  of  data  present  in  a 
sophisticated  computer  file  containing  full  product  descriptions.  Limited  or 
condensed  product  descriptions  are  currently  transmitted.  Magnetic  tape 
systems  are  not  effective  for  rapid  and  frequent  exchanges. 
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•  System  performance/workstation  functionality  —  More  advances  are  needed 
in  workstation  speed,  power,  and  compression  techniques  to  store  large 
amounts  of  data. 

•  Proprietary  database  security  —  In  many  cases,  prime  contractors  are 
allowing  subcontractors  direct  access  to  product  descriptions  and  internally 
developed  application  software.  The  activity  could  be  increased  if  effective 
methods  were  developed  to  control  who  is  allowed  to  access  data  systems  and 
who  is  allowed  to  manipulate  accessed  data  or  software. 

4.2.2  Dynamic  Environment 

In  addition,  product  data  exchange  capabilities  are  in  a  highly  dynamic  and  evolving 
environment  which  makes  implementation  and  standards  extremely  difficult  to  manage.  The 
issues  that  illustrate  this  problem  are: 

•  Numerous  levels  of  implementation  —  The  current  standards,  such  as  IGES, 
a  °!  not  implemented  to  the  same  extent  by  CAD/CAM  system  developers. 

Da*. 1  conversion  from  one  system  to  another  can  thus  become  very  time 
consu.  ling  and  error  prone.  Also,  companies  differ  in  the  degree  to  which  they 
commit  to  this  technology. 

•  Technology  in  rapid  state  of  change  —  Today,  state-of-the-art  systems  can 
become  obsolete  quickly.  For  this  reason,  some  companies  wait  for  the  system 
that  is  the  “best”  system  for  them.  Others  are  continually  experimenting  with 
new  capabilities. 

•  Overlapping  technologies  —  Currently,  companies  are  installing  systems, 
such  as  optical  disk  systems,  to  automate  the  storage,  retrieval,  and  archiving 
of  drawings.  These  systems  require  communication  networks,  specialized 
terminals,  computers,  and  so  on.  In  parallel  to  this,  companies  are  also 
attempting  to  integrate  their  CAD/CAM  systems  for  the  use  and  manipula¬ 
tion  of  intelligent  drawings.  Again,  these  systems  require  communication 
networks,  specialized  terminals,  computers,  and  so  on.  In  most  cases,  only  a 
small  percentage  of  the  hardware/software  environment  is  common  to  both 
implementations.  This  creates  problems  in  financial  justification,  training, 
establishing  operational  procedures,  and  so  on. 

•  Dual  manual/computerized  environment  —  Manual  systems  do  not  change  to 
a  totally  computerized  system  overnight.  Companies  have  to  keep  both 
systems  going  while  they  are  transitioning  and  pay  an  operational  cost 
penalty  in  the  transition. 

•  Standards  for  a  rapidly  evolving  technology  —  The  IGES/PDES  efforts  are 
attempting  to  standardize  a  technology  that  is  not  yet  developed.  The  PDES 
effort  is  more  of  a  R&D  activity  than  a  standardization  effort. 

•  Education/training  gap  —  Employees  throughout  an  enterprise  must  be 
trained  not  only  how  to  use  product  data  generation,  manipulation,  and 
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transfer  equipment  but  also  how  to  use  it  efficiently  and  effectively. 
Employees  must  learn  that  failure  to  look  at  the  overall  control  requirements 
of  the  system  may  result  in  problems  later  in  the  product  life  cycle.  Employees 
in  the  life  cycle  range  from  those  with  great  expertise  in  using  computers  to 
those  with  no  computer-based  knowledge. 

4.2.3  Integrated  Approach 

Other  issues  deal  with  the  need  of  product  data  exchange  to  be  addressed  in  light  of  the 
entire  life  cycle,  introducing  integration  challenges. 

•  Heterogeneous  computing  environment  —  Users  are  not  all  going  to  acquire 
one  single  system.  There  is  not  one  single  solution  to  all  product  data  transfer 
.  problems.  Different  computer  systems  will  prevail  among  companies  and  the 

challenge  becomes  one  of  integrating  these  system*.  hopefully,  to  the  degree 
that  it  becomes  transparent  to  the  user. 

•  Nc  -^standard  representations  of  data  —  There  are  various  ways  of  creating  a 
speci  ~c  geometric  feature,  such  as  a  spline,  among  system  developers.  As  a 
result,  product  data  transfers  are  sometimes  impossible;  other  times,  the 
accuracy  is  uncertain. 

•  Turnkey  systems  not  adaptable  —  Many  available  systems  do  not  meet  the 
specific  needs  of  many  companies  with  unique  product  lines.  Also,  they  are 
not  easily  adaptable  to  meet  the  company’s  unique  needs  or  the  company  is 
not  large  enough  to  employee  the  resources  necessary  to  modify  such  a 
system.  On  the  other  hand,  many  companies  that  acquire  such  systems  and 
modify  them  to  fit  their  unique  needs  discover  that  their  system  is  no  longer 
compatible  with  others  of  the  same  manufacture. 

•  Full  life  cycle  coverage  —  Single  product  databases  that  can  be  used  by  the 
many  islands  of  automation  in  the  life  cycle  of  a  product  do  not  exist. 
Numerous  translators  are  required  to  provide  product  data  transfer  effectively 
among  the  many  life  cycle  operations.  Translations  are  considered  deficient 
for  many  applications. 

•  Interface  to  application  software  —  Existing  application  software  can 
generally  use  the  databases  that  are  now  available.  However,  as  we  move 
toward  the  use  of  full  product  description  databases,  we  will  be  required  to 
develop  new  interfaces  to  these  existing  applications.  But,  we  will  also  have 
the  opportunity  to  automate  life  cycle  applications  that  previously  needed  a 
more  complete  database. 

•  F"iback  to  design  —  Existing  iterative  design  cycles  do  not  always  provide 
the  designer  with  the  information  required  for  accurate  decision-making  early 
in  the  design  process.  Advances  in  product  data  transfer  technology  will 
provide  more  opportunities  for  effective  feedback  of  information  to  the  design 
process. 
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4.2.4  Special  DoD  Requirements 

Special  DoD  requirements  compound  the  general  industry  requirements. 

•  Methods  of  handling  classified  and  proprietary  rights  data  —  For  reasons  of 
security,  there  is  a  need  for  companies  that  deal  with  defense  contracts  to 
control  access  to  certain  databases  while  they  allow  direct  access  by  suppliers 
or  dual  source  manufacturers  to  other  databases. 

•  Applications  in  Air  Logistic  Centers  (ALCs)  —  ALCs  will  be  increasing  their 
use  of  product  data  transfer  applications  to  help  reduce  maintenance  costs  of 
weapons  systems  and  to  enhance  the  benefits  of  dual  sourcing.  The  greatest 

.  benefits  will  come,  again,  from  the  use  of  full  product  descriptions. 

•  High-risk  designs  —  Weapons  systems  are  by  nature  frequently  at  the  leading 
edge  of  technology.  This  requires  product  data  exchange  to  be  adaptable  and 
flexible  in  encountering  new  and  previously  unknown  configurations  and 
products.  Implied  is  the  extra  DoD  need  to  accommodate  rapid  change  in  the 
product  cycle. 
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SECTION  5 

FUTURE  CHALLENGES 


Section  4  discussed  the  technical  issues  impeding  product  data  transfer.  As  the  first  step  in 
addressing  these  issues,  efforts  need  to  be  initiated  or  continued  in  several  areas  directly  related 
to  the  GMAP  work.  These  areas  are: 

•  Development  of  a  complete  specification  for  PDD 

•  Standards  for  the  representation  of  PDD  data 

•  Development  of  a  product  modeler  and  the  standardization  of  the  components 
of  a  product  modeler 

•  Integration  of  PDD  with  other  corporate  databases/knowledge  bases 

•  Integration  of  PDD  with  supplier  base. 

5.1  COMPLETE  SPECIFICATION  FOR  PDD 

GMAP  focused  on  the  PDD  needs  and  requirements  for  turbine  blades  and  disks.  This 
work  must  be  expanded  to  include  all  part  types  and  all  applications.  The  current  CALS 
MIL-D-28000  (for  IGES),  PDES  Inc.  efforts  to  define  Context  Driven  Information  Models 
(CDIM),  and  the  IGES/PDES  organizations  activities  to  define  application  protocols  are  all 
attempts  to  address  this  shortfall.  These  efforts  are  aimed  at  defining  the  information  content 
required  to  fully  support  specific  application  areas.  The  expectation  is  that  the  sum  total  of  these 
information  packages  will  result  in  a  specification  that  will  completely  address  PDD  throughout 
the  total  life  cycle. 

More  work  needs  to  be  accomplished  to  address  each  application  area  within  the  life  cycle. 
We  recommend  that  the  Air  Force,  and  other  Government  agencies,  continue  funding  NIST  to 
head  the  coordination  for  the  development  of  PDES.  We  further  recommend  that  NIST  be 
funded,  in  cooperation  with  PDES  Inc.,  to  work  with  the  Government  Interagency  PDES  Group 
in  creating  a  composite  listing  of  all  application  areas  throughout  the  life  cycle.  The  listing  could 
be  correlated  by  industry  to  create  a  matrix  that  can  be  prioritized.  This  will  allow  the 
development  of  the  PDES  specification  in  logical  steps  by: 

•  First  creating  a  core  information  model  that  is  chartered  to  support  weapons 
systems 

•  Secondly,  providing  a  global  map  for  the  expansion  of  this  core  to  encompass 
and  support  the  information  needs  of  all  applications  across  all  industries. 

5.2  ESTABLISH  STANDARDS  FOR  PDD  REPRESENTATION 

Explicit  in  a  complete  PDD  specification  is  the  standard  for  its  representation.  Adherence 
is  necessary  to  avoid  costly,  error  prone,  and  often  computer-intensive  translations.  The  PDES 
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and  IGES  communities  have  continually  wrestled  with  the  specification  of  standard  mathemati¬ 
cal  representation  of  geometric  data;  in  particular,  for  splined  curve  and  surface  entities. 

Agreement  and  standardization  are  inhibited  by  the  fact  that  many  corporations  have  made 
significant  investments  in  commercial  and  in-house  systems  that  predate  current  standards 
activities.  The  cost  of  conversion  to  a  single  standard  may  be  prohibitive.  This  cost  factor, 
coupled  with  the  realizations  that  no  single  representation  is  sufficient  for  ah  needs,  and  that 
new  mathematical  techniques  and  representations  are  continually  evolving,  present  a  challenge 
for  commonality  and  standardization.  We  recommend  that  the  PDES  community  work  with  the 
appropriate  standardization  organizations  to  issue  recommended  practices,  parameterizations, 
standard  word  lengths,  and  guidelines  for  the  use  of  geometrical  PDD.  The  guidelines  need  to  be 
included  for  each  of  the  application  protocols  and  they  must  encompass  different  pan  families 
such  as  turned  parts,  machined,  sheet  metal,  composites,  and  electrical  components. 

Within  each  part  family,  there  are  optimal  geometric  modeling  techniques  and  mathemati¬ 
cal  representations.  To  enable  the  user  community  to  embrace  and  properly  use  PDD,  we 
recommend  that  a  standard  computer  sensible  data  dictionary  be  made  available. 

5.3  DEVELOP  PRODUCT  MODELER 

Current  CAD/CAM  systems  in  the  aerospace  industry  do  not  support  the  ability  to  provide 
complete  PDD  part  models.  These  systems  provide  only  the  shape  (geometry  and  topology) 
information  and  very  little  of  the  nonshape  information  that  is  needed.  In  fact,  until  the  GMAP 
effort,  information  such  a.^  inspection  zone  information  needed  for  logistics,  had  never  before 
been  represented  in  digital  format  as  PDD. 

GMAP  used  a  rudimentary  editor  to  supplement  existing  CAD/CAM  systems  to  create  this 
additional  information.  This  was  adequate  to  provide  support  for  proof-of-concept  demonstra¬ 
tions  and  to  continue  our  support  of  the  F100  models  teeded  by  IBIS.  It  is  not  a  method  that  is 
desirable  to  u«e  regularly  on  a  production  basis.  The  ability  is  needed  to  create  full  product 
models  much  the  sam^  way  that  we  use  CAD/CAM  systems  today.  Based  on  the  GMAP 
experience  in  creating  the  original  GMAP  PDD  models,  the  baseline  requirements  for  a  product 
modeler  were  documented.  The  product  modeler  document  outlines  the  technology  voids  of 
today’s  CAD/CAM  systems  and  is  a  guide  to  assist  CAD/CAM  system  developers  in 
understanding  industry’s  needs  and  requirements.  It  is  anticipated  that  system  developers  will 
use  this  document  as  a  baseline  to  create  system  specifications  that  can  be  used  to  develop  the 
next  generation  of  CAD/CAM  systems  —  product  modelers. 

Industry  and  Government  must  continue  to  work  closely  with  system  developers  to  ensure 
that  manufacturing  industry  needs  are  addressed  in  the  new  products  rhat  are  being  developed. 
We  recommend  that  a  project  be  funded  that  will  define  a  framework  for  the  development  of 
related  standards  that  must  be  defined.  A  time  table,  consistent  with  the  CALS  objectives,  must 
be  established  and  work  begun  on  the  development  of  the  needed  specifications. 

5.4  INTEGRATE  PDD  WITH  OTHER  DATABASES 

There  is  a  growing  national  awareness  that  information  must  be  managed  and,  that  for 
information  to  be  useful,  it  roust  be  transformed  into  knowledge.  Today,  computerisation  in 
industry  has  resulted  in  “Islands  of  Information’’  that  reside  on  a  multitude  of  hardware  and 
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software  platforms.  This  information  is  not  easily  accessible  and  is,  therefore,  not  available  to  be 
shared  throughout  an  enterprise.  To  enable  these  databases  to  be  shared  between  locations, 
applications,  and  systems,  they  must  be  integrated.  Several  Government  and  industry  initiatives 
are  already  underway  to  help  resolve  the  task  of  integrating  existing  corporate  databases. 

GMAP  studied  the  problem  of  integrating  the  information  needed  to  define  a  product,  that 
is  PDD.  As  a  result  of  this  work,  a  system  architecture  was  prototyped  that  provided  a 
mechanism  to  communicate  and  share  PDD  across  life  cycle  boundaries.  The  next  step  is  to  add 
the  GMAP  concepts  on  the  integration  of  PDD  to  the  efforts  of  integrating  the  business  data  of 
an  enterprise.  To  this  end,  we  recommend  the  funding  of  programs  such  as  OLIS  (On-Line 
Information  System)  that  will  address  the  integration  problems  through  focused  research  and 
development.  Research  is  needed  to  address  the  fundamental  technology  shortfalls  that  exist  in 
areas,  such  as: 

•  Open  architecture 

•  Networking 

•  Database  management  system  support  for  PDD 

'  Knowledge  representation  of  product  and  process  data 

•  Parallel  processing 

•  Expert  systems  and  databases 

•  Distributed  technology. 

To  be  successful,  it  is  recommended  that  system  developers  be  strongly  encouraged  to 
participate  so  they  will  develop  ownership  of  the  ideas  and  concepts  that  result  from  this 
research  and  be  appropriately  motivated  to  develop  commercial  products. 

5.5  INTEGRATE  PUD  WITH  SUPPLIER  BASE 

The  small  and  medium  sized  companies,  those  who  are  suppliers  to  the  prime  aerospace 
contractors,  must  be  fully  integrated  into  the  dataflow.  Until  corporate  databases  are  more  fully 
integrated,  only  small  inroads  can  be  made  in  integrating  the  supplier  base.  In  the  interim,  it 
would  be  very  productive  to  educate  these  companies  on  the  impact  that  this  integration  and 
dataflow  will  have  on  their  businesses.  They  will  need  this  understanding  to  invest  wisely  in  the 
types  of  computer  hardware  and  software.  They  will  also  need  the  appropriate  people  to  support 
their  businesses  in  the  future.  These  will  not  be  easy  to  obtain. 

We  recommend  that  a  program,  similar  to  the  Machining  Initiative  for  Aerospace 
Subcontractors  (MIAS),  be  funded  to  study  supplier  companies  and  determine  the  needs, 
requirements,  and  most  of  all,  the  benefits  to  be  gained  from  the  use  of  computerized  data  in  an 
integrated  network  with  the  prime  contractors. 

We  also  recommend  that  the  supplier  IMIP  programs  include  assistance  to  suppliers  for 
computerizing  their  factories  to  facilitate  the  interchange  of  data. 

Further,  we  recommend  that  the  current  NIST  efforts  to  transfer  the  AMRF  results  to  mid- 
and  small-sized  business  through  the  Manufacturing  Technology  Centers  Program  be  coupled 
with  the  above  mentioned  “MIAS-like  program.”  This  would  focus  the  efforts  tnat  are  trying  to 
reach  the  backbone  of  American  industries,  the  small-to-mid-size  companies,  and  encourage 
them  to  step  up  to  the  needed  modernization. 


5-3 


RJM02*K 


